1. Field of the Invention
The invention relates in to a circuit simulator that forks a simulation process at checkpoints to create a suspended checkpoint processes that can be resumed to initiate re-simulations from the checkpoints.
2. Description of Related Art
Digital IC designers use a hardware description language (HDL) such as Verilog, VHDL or SystemC to create a circuit design in the form of a behavioral description of an electronic circuit. Referring to FIG. 1, the design 100 describes a circuit as being formed by instances of transistors, logic gates and other devices that are interconnected by nets, interfaces or channels. Each device may be an instance of a standard cell having an internal structure described by a cell library 102, which also includes a mathematical module of cell behavior. The design usually organizes cell instances into a hierarchy of modules. For example in FIG. 1, design 100 organizes cell instances into a set of three high-level module instances A, B and C. Module A includes two lower level modules D and E, and module E includes two lower level modules F and G.
After creating the HDL design 100 for a circuit, a designer can employ a computer-based circuit simulator 104 to determine how the circuit it describes would respond to input signals based on the behavioral models provided by cell library 102. A “testbench” 106 includes the HDL design 100 describing the circuit along with statements 108 for controlling the time-varying behavior of test signal inputs to be applied to the circuit during the simulation and may include control statements 110 specifying various parameters of the simulation. A user may also provide control statements through a command script 111 that the simulator imports. Control statements 110 or command script 111 may tell simulator 104 to generate and save waveform data 112 representing the time-varying behavior of various signals the simulated circuit produces during the simulation. Following the simulation, a user can analyze waveform data 112 using a debugger 114, which produces waveform and other displays that help the designer debug the circuit.
Since simulator 104 usually produces much more waveform data during a simulation than it can store in random access memory (RAM), it must halt the simulation from time-to-time to write the waveform data it has generated to a hard disk 118 or other storage device so that it can free RAM space for more waveform data. It then resumes the simulation. A simulator can require many hours to simulate a large circuit, and may spend much of that time writing waveform data 112 to hard disk 118 because disk accesses are relatively slow. To reduce simulation time, a designer will usually program simulator 104 to save waveform data 112 for only a limited number of simulated circuit signals so that it need not spend so much time writing waveform data to hard disk 118. For example, a designer will often initially configure simulator 104 to save only waveform data representing the circuit input signals and the output signals of the various circuit modules and to discard waveform data representing behavior of the internal signals of most modules.
When debugging a circuit design based on waveform data 112 representing only module input and output signals, a designer may be able to deduce from the behavior of a module output signal that a particular module has a design error, but may not be able to track the error to any particular portion of that module since simulator 104 did not save waveform data representing behavior of signals that are internal to that module. In such case a designer may change control statements 110 of testbench 106 so that the simulator saves waveform data representing the internal signals of the particular module suspected of having a design flaw. After simulator 104 re-simulates the circuit and saves that more detailed waveform data 112, the designer can investigate the behavior of that module in more detail. A drawback to this approach is that re-simulations can require as much or more processing time as the original simulation, and since a designer may have to run several re-simulations in order to fully debug a design, the debugging process can be very time-consuming.
Designers have reduced re-simulation processing time by reducing the scope of the re-simulation so that the simulator re-simulate behavior only the modules believed to contain design flaws. Suppose, for example, that after reviewing waveform data representing output signals of each of the modules the designer deduces there is an error in module B and wants to collect waveform data for internal signals within module B during a re-simulation. The designer can reduce re-simulation time by modifying test bench 106 so that simulator 104 need re-simulate only module B and so that the testbench generates the input signals to module B based on waveform data 112 representing those module B input signals saved during the original simulation. Processing time for the re-simulation decreases simulator 104 need not simulate behavior of modules A and C.
Another known way to reduce re-simulation processing time is to limit the time span of the re-simulation. FIG. 2 shows a timeline for an example simulation in which a simulator requires one hour of processing time to simulate 1000 nanoseconds of circuit operation. In this example an initial simulation spanned 4500 nanoseconds of simulation time and required 4.5 hours of processing time. While subsequently debugging the results of the simulation, a designer discovered an error in a monitored signal at time T=2800 ns and suspects that the error propagated from errors in internal signals of one or more modules resulting from flawed logic during a limited period leading up to time T. The designer would like initiate a re-simulation to obtain waveform data for the internal signals, but rather than starting the re-simulation at simulation time 0 and ending it at simulation time 4500, the designer could reduce processing time by starting the re-simulation at a time closer to T and ending it immediately after simulation time T. A digital circuit typically includes devices such as registers, latches, flip-flops and random access memories that store data. The “state” of a simulated circuit at any given moment during the simulation is a function of the state of each data bit stored in those memory devices. The testbench defines the initial state of each stored bit at the beginning of the simulation (time T=0), but the state of those bits change as the simulation progresses. At any given moment during a simulation, the response of the simulated circuit to its input signals depends not only on the states of its input signals, but also on the states of data stored in its internal memory devices, which in turn depends on the history of its input signals. Hence if a simulator is to run a re-simulation starting at some time Tx>0, it is necessary that the re-simulation begin with all the simulated circuit's stored data set to the states they would have had at time Tx if the re-simulation had run from time 0 to time Tx.
Referring again to FIGS. 1 and 2 it is known to include control statements 110 in a testbench 106 for an original simulation that tell the simulator 104 to periodically stop the simulation and save “checkpoint data” 116 defining the current state of the simulation to a hard disk 118. As illustrated in FIG. 3, in addition to providing a kernel address space 120, random access memory (RAM) 122 of a computer processor executing a simulation process includes space for a block of simulation program code 124, for global variables 126, for a heap 128 and for a stack 130 employed by the simulation process. The simulation process will also employ various registers 132 within the computer processor for storing data. The checkpoint data 116 needed to save the current state of the process includes the global variables 126, the heap 128, the stack 130, and the contents of registers 132, along with other information 134 such as, for example, a file descriptor for identifying the checkpoint and any other information needed to restart the simulation program at the correct point. To restart the process from the checkpoint, it is necessary to read the checkpoint data 116 from the hard disk and write it back to the RAM and register locations it came from. Simulator program code 124 (i.e., testbench code), which may have been modified for the re-simulation, is also reloaded into memory 122 from its storage location elsewhere on the hard disk.
In the example of FIG. 2, the simulator was configured to save checkpoint data after 1000 ns of simulation time, which requires one hour of processing time, and the simulator therefore saved four blocks of checkpoint data during the original 4.5-hour simulation. Since the designer is only interested in re-simulating the circuit during a time immediately preceding time T=2800 ns, it is possible to restart the simulation at time Tx=2000 ns and end it at simulation time 2800 ns by using the checkpoint data saved at time 2000 ns to initialize the state of the simulation and by altering control statements in the testbench to tell the simulator to end at time 2800 ns. This saves 2 hours of processing time over starting the re-simulation at time 0.
The drawback to saving checkpoint data during the original simulation is that it requires disk accesses, which are time-consuming. The more frequently simulator 104 saves checkpoint data 116, the higher the resolution with which a designer is able to select starting times for subsequent re-simulations. For example if the designer is only interested in re-simulation the circuit for 100 ns of simulation time immediately preceding time T, re-simulation time could be further reduced if simulator 104 had been configured to save checkpoint data 116 after every 100 ns of simulation time. However, since saving checkpoint data to hard disk 118 is time-consuming, a designer would not configure simulator 104 to save checkpoint data too frequently because doing so would dramatically slow the original simulation.